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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The present document defines the interfaces and Terminal Adaptation Functions (TAF) integral to a Mobile 
Termination (MT) which enables the attachment of synchronous terminals to a MT within the 3GPP system. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines Terminal Adaptation Functions (TAF) which are integrated in a Mobile Termination 
(MT) and which enable the attachment of Synchronous Terminals to an MT (see GSM 04.02 [3]). The general aspects 
of Terminal Adaptation Functions are contained in specification 3G TS 27.001 [9]. The present document covers 
support of synchronous data services (see 3G TS 22.002 [6]) for the following interfaces and procedures: 

- V.22[15] DTE/DCE Interface; 

- V.22bis[16] DTE/DCE Interface; 

- V.26 ter [19] DTE/DCE Interface; 

- V.32[21] DTE/DCE Interface; 

- X.21 [23] DTE/DCE Interface; 

- X.21 bis [24] DTE/DCE Interface; 

- X.32 [30] Procedure; 

- V.25bis[18] Procedure; 

- 1.420 [11] Interface (S). 

LAPB is the only synchronous non-transparent protocol which is considered in the present document. 

NOTE: From GSM R99 onwards the following services are no more required to be provided by a GSM PLMN: 

the dual Bearer Services "alternate speech/data" and "speech followed by data"; 

the dedicated services for PAD and Packet access; 

- BS21 ... 26andBS31 ... 34. 

The support of these services is still optional. The specification of these services is not within the scope of the present 
document. For that, the reader is referred to GSM Release 98. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[1] GSM 01.04: "Digital cellular telecommunication system (Phase 2+); Abbreviations and 

acronyms". 

[2] GSM 03.10: "Digital cellular telecommunication system (Phase 2+); GSM Public Land Mobile 

Network (PLMN) connection types". 

[3] GSM 04.02: "Digital cellular telecommunication system (Phase 2+); GSM Public Land Mobile 

Network (PLMN) access reference configuration". 

[4] GSM 04.21: "Digital cellular telecommunication system (Phase 2+); Rate adaption on the Mobile 

Station - Base Station System (MS - BSS) interface". 
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[5] GSM 08.20: "Digital cellular telecommunication system (Phase 2+); Rate adaption on the Base 

Station System - Mobile-services Switching Centre (BSS - MSC) interface". 

[6] 3G TS 22.002: "Circuit Bearer Services (BS) supported by Public Land Mobile Network 

(PLMN)". 

[7] 3G TS 24.008: "Mobile Radio Interface Layer 3 specification; Core Network Protocols-Stage 3". 

[8] 3G TS 24.022: "Radio Link Protocol (RLP) for Circuit Switched Bearer and Teleservices". 

[9] 3G TS 27.001 : "General on Terminal Adaptation Functions (TAF) for Mobile Stations (MS)". 

[10] 3G TR 2L905: "3G Vocabulary". 

[11] ITU-T Recommendation 1.420 (1998): "Basic user-network interface". 

[12] ITU-T Recommendation Q.931: "ISDN user-network interface layer 3 specification for basic call 

control". 

[13] ITU-T Recommendation V.IO: "Electrical characteristics for unbalanced double-current 

interchange circuits operating at data signalling rates nominally up to 100 kbit/s". 

[14] ITU-T Recommendation V.l 1: "Electrical characteristics for balanced double-current interchange 

circuits operating at data signalling rates nominally up to 10 Mbit/s ". 

[15] ITU-T Recommendation V.22 (1988): "1200 bits per second duplex modem standardized for use 

in the general switched telephone network and on point-to-point 2-wire leased telephone-type 

circuits". 

[16] ITU-T Recommendation V.22 bis (1988): "2400 bits per second duplex modem using the 

frequency division technique standardized for use on the general switched telephone network and 
on point-to-point 2-wire leased telephone-type circuits". 

[17] ITU-T Recommendation V.24 (1996):"List of definitions for interchange circuits between data 

terminal equipment (DTE) and data circuit-terminating equipment (DCE)". 

[18] ITU-T Recommendation V.25 bis (1996): "Synchronous and asynchronous automatic dialling 

procedures on switched networks". 

[19] ITU-T Recommendation V.26 ter (1988): "2400 bits per second duplex modem using the echo 

cancellation technique standardized for use on the general switched telephone network and on 
point-to-point 2-wire leased telephone-type circuits". 

[20] ITU-T Recommendation V.28 (1993): "Electrical characteristics for unbalanced double-current 

interchange circuits". 

[21] ITU-T Recommendation V.32 (1993): "A family of 2-wire, duplex modems operating at data 

signalling rates of up to 9600 bit/s for use in the general switched telephone network and on leased 
telephone-type circuits". 

[22] ITU-T Recommendation V. 1 10 (1996): "Support of data terminal equipments with V-Series 

interfaces by an integrated services digital network". 

[23] ITU-T Recommendation X.21 (1992): "Interface between Data Terminal Equipment and Data 

Circuit-terminating Equipment for synchronous operation on public data networks". 

[24] ITU-T Recommendation X.21 bis (1988): "Use on public data networks of Data Terminal 

Equipment (DTE) which is designed for interfacing to synchronous V-Series modems". 

[25] ITU-T Recommendation X.24 (1988): "List of definitions for interchange circuits between Data 

Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) on public data 
networks". 

[26] ITU-T Recommendation X.26 (1993): "Electrical characteristics for unbalanced double-current 

interchange circuits operating at data signalling rates nominally up to 100 kbit/s ". 
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[27] ITU-T Recommendation X.27 (1996): "Electrical characteristics for balanced double-current 

interchange circuits operating at data signalling rates up to 10 Mbit/s". 

[28] ITU-T Recommendation X.30 (1993): "Support of X.21, X.21 bis and X.20 bis based Data 

Terminal Equipment (DTEs) by an Integrated Services Digital Network (ISDN)". 

[29] ITU-T Recommendation X.31 (1995): "Support of packet mode terminal equipment by an ISDN". 

[30] ITU-T Recommendation X.32 (1996): "Interface between Data terminal Equipment (DTE) and 

Data Circuit-terminating Equipment (DCE) for terminals operating in packet mode and accessing a 
Packet-Switched Public Data Network through a public switched telephone network or an 
Integrated Services Digital Network or a Circuit-Switched Public Data Network". 

[31] ISO Recommendation 8885: "Information technology - Telecommunication and information 

exchange between systems - High-level data link control (HDLC) procedures - General purpose 
XID frame information field content and format" . 

[32] ISO Recommendation 8886: "Information technology - Telecommunication and information 

exchange between systems - Data link service definitions for Open Systems interconnection". 

[33] Personal Computer Memory Card Association: "PCMCIA 2. 1 or PC -Card 3.0 electrical 

specification or later revisions". 

[34] Infrared Data Association IrDA: "IrPHY Physical layer signalling standard". 

2.1 Abbreviations 

In addition to the abbreviations listed below, the present document also uses termslisted in 3GTR 21.905 [10] and 
GSM 01.04 [1]. 

AU Access Unit 

BORE Bit Oriented Relay Entity 

EDGE Enhanced Data for Global Evolution 

FES For further studies 

IrDA Infrared Data Association 

IrPHY InfraredPHYsical layer 

ITU-T ITU-Telecommunication Standardization Sector 

MUX Multiplexer 

PCMCIA Personal Computer Memory Card Association 

PC Personal Computer 



3 General 

3.1 Customer access configuration 

The GSM PLMN access reference configuration is described in figure 1 of GSM 04.02 [3]. The present document 
specifically refers to the MTs which support terminal equipments (TEl or TE2) that use synchronous bearer 
capabilities. 
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3.2 Terminal Adaptation Function 



The TAF is functionally part of an MTO, MTl or MT2 (see GSM 04.02 [3]). The terminal adaptation provides facilities 
to allow manual or automatic call control functions associated with circuit switched data services, in case of ITU-T V 
series interfaces. The ITU-T X.21[23] DTE/DCE interface allows only for automatic call control functions. The 
following functions are included: 

conversion of electrical, mechanical, functional and procedural characteristics of the ITU-T V-series, ITU-T 
X-series and ISDN type interfaces to those required by a GSM PLMN; 

- bit rate adaptation of ITU-T V-series and ITU-T X-series data signalling rates and the ISDN 64 kbit/s to that 
provided in the GSM PLMN; 

- the mapping of ITU-T V.25 bis [18] AUTO CALL/AUTO ANSWER procedures and ITU-T X.21[23] 
procedures to the GSM PLMN Dm-channel signalling; 

the mapping functions necessary to convert ITU-T S-interface signalling to PLMN Dm-channel signalling; 

synchronization procedure, which means the task of synchronizing the entry to and the exit from the data transfer 
phase between two subscriber terminals. This is described in the specification 3G TS 27.001 [9]; 

filtering of channel control information. This is described in the specification 3G TS 27.001 [9]; 

- compatibility checking (see 3G TS 27.001 [9]); 
layer 2 relaying (see annex 1); 

flow control; 

in Call Modification function (see clause 4); 

splitting and combining of the data flow in case of multi substream data configurations. 

3.3 TAF Interfacing to other MT functions 

TAF interfacing is shown in figure 1 . 



TAF 




Mobility Management 










RR Management 










Cinannel Codec FEC 





MMI 



Call Control 



Figure 1 : TAF interfacing to other lUIT functions 



4 Terminal Adaptation Functions for synchronous 

transparent services 

Specification GSM 03.10 [2] refers to the models for connection types supporting synchronous transparent services. 
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4.1 Rate Adaptation in GSIVI 



Rate adaptation on the MS-BS interface is described in GSM 04.21 [4]. The synchronous data services make use of the 
following rate adaptation functions: RAl, RA2, RAl/RAl', RAl' and in case of TCH/F28.8 usage, EDGE-MUX. See 
also figures 6, 7 and 8 in GSM 03.10 [2]. The D-bits of the rate adaptation frames are used to convey user data and the 
S- and X-bits are used to convey channel status information associated with the data bits in the data transfer state, or to 
carry substream numbering between the Split/Combine functions in case of mult substream operation. For the S- and 
X-bits, a ZERO corresponds to the ON condition, a ONE to the OFF condition. 



4.1 .1 Rate adaptation - ITU-T V-series 



This is provided as indicated in specification GSM 04.21 [4]. The functions applied in this case are shown in figure 2 
(see model 2b in figures 6, 7 and 8 of GSM 03.10 [2]). 
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(data and control) 




MT2 
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V-series 






RAl' 
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Figure 2: Rate adaptation for V-series terminals 

4.1 .2 Rate adaptation - ITU-T X.21 

This is provided as indicated in specification GSM 04.21 [4]. The functions applied in this case are shown in figure 3 
(see model 2b in figures 6, 7 and 8 of GSM 03.10 [2]). 
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Figure 3: Rate adaptation for ITU-T X.21 [23] terminals 



4.1 .3 Rate adaptation - ITU-T S-interface 

The functions applied in this case are shown in figure 4 (see model 2a in figures 6, 7 and 8 of GSM 03.10 [2]). 
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Figure 4a: Rate adaptation for ITU-T S-interface 
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Figure 4b: Rate adaptation for ITU-T S-interface (continued) 
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There are two cases to be considered for the RAl function: 

a) V-series interface: 

for the V-series type of terminal equipments the rate adaptation functions are as described in GSM 04.21 [4]. 

b) ITU-T X.21 [23] -interface: 

for terminal equipments using the ITU-T X.21 [23] -interface the rate adaptation functions are identical to 
those described in GSM 04.21 [4], but the notation used is as described in ITU-T recommendation X.30 [28]; 

the notation used is as follows: 

the conversion of the user rates of 2.4 kbit/s and 4.8 kbit/s to 8 kbit/s and user rate of 9.6 kbit/s to 
16 kbit/s shall be implemented by means of the 40 bit frame structure shown in figure 5; 

figure 5 shows that in addition to the basic frame, a two frame multiframe is employed. In odd frames, 
octet contains all zeros, whilst in even frames octet consists of a one followed by seven E bits. The 
order of bit transmission of the 40 bit frame is from left-to-right and top-to-bottom; 

this two frame multiframe corresponds to the 80 bit frame structure presented in GSM 04.21 [4] as shown 
in figure 6. The 24 information bits P1,..,P8, Q1,..Q8, R1,..,R8 of odd frames correspond with D1,..,D24 
and those of even frames correspond with D25,..,D48 respectively. For the status bits there is the 
following correspondence: odd frame SQ, X, SR, SP = S1,X,S3,S4 and even frame SQ, X, SR, SP = S6, 
X, S8, S9. 

option for a manufacturer of mobile stations: 

in transparent mode support of a packet mode TEl or TE2ArA, which uses flag stuffing. 





Bit number 
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1 R3 R4 R5 R6 R7 R8 


SP 


NOTE: 


Bit X, if not used for the optional flow control or for the indication of the far end synchronization 
set to (see ITU-T Recommendation V.1 10 [22]). 


, shall be 



Figure 5: 40 bit frame structure of ITU-T X.30 [28] 
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Figure 6: Correspondence of ITU-T X.30 [28] and ITU-T V.1 10 [22] frames 
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4.2 Interchange Circuit Signalling Mapping 
4.2.1 ITU-T V-series interchange circuit mapping 

The interchange circuit signalHng mapping at the interface between the TE2 and the MT shall conform to ITU-T 
recommendation V.24 [17]; while the signal levels at the interface shall conform either to ITU-T recommendation 
V.28 [20], or to IrDA IrPHY Physical signalHng standard specification [34], or to PCMCIA 2.1 [33], or to 
PC -Card 3.0 [33] electrical specifications or to later revisions. 

The signals required at this interface are shown in table 2. 

Specification GSM 04.21 [4] refers to the frame structure and identifies the use of status bits for the carriage of 
signalling information 

Status bits SA, SB and X are used to convey channel control information associated with the data bits in the data 
transfer state. Table 1 shows the mapping scheme between the ITU-T V.24 [17]circuit numbers and the status bits for 
the transparent mode. It also shows how the unused status bits should be handled. It is derived from the general 
mapping scheme described in annex C. A binary corresponds to the ON condition, a binary 1 to the OFF condition. 

The transport of these status bits by the various channel codings is described in subsequent sections. 
Table 1 : Mapping scheme at the IVIT for the transparent mode 



Signal at TE2/MT 

interface or condition 

within the MT 


Mapping 
direction: MT to IWF 


Mapping 
direction: IWF to MT 


CT105 


not mapped (note 1) 




CT106 




from status bit X (note 7) 


CT107 




not mapped (note 5) 


C1 1 08/2 


not mapped (note 6) 




CT109 




from status bit SB (note 7) 


CT133 


not mapped (note 2) 




always ON 


to status bit SA (note 3) 




always ON 


to status bit SB (note 1) 




always ON 


to status bit X (note 4) 




ignored by MT 




from status bit SA (note 3) 


NOTE 1 : The SB bit towards the IWF, according to the General Mapping (27.002, 
annex C), could be used to carry CT 105. However, CT 105 should 
always be ON in the data transfer state since only duplex operation is 
supported. Also, many DTEs use the connector pin assigned to CT 105 
for CT 1 33. No interchange circuit shall be mapped to the SB bit which 
shall always be set to ON in the data transfer state. 

NOTE 2: CT 133 is not mapped since there is no flow control in transparent mode. 

NOTE 3: The SA bits in both directions are available only with certain channel 
codings. Therefore, for maximum compatibility, they should not be 
mapped. 

NOTE 4: The X bit towards the IWF is not mapped and shall always be set to ON in 
the data transfer state since there is no flow control in transparent mode. 

NOTE 5: CT 107 is controlled by the channel synchronization process 
{3G TS 27.001 [9]). 

NOTE 6: CT 108/2 may be used in the call setup and answering processes. 

NOTE 7: The status bits are filtered before being mapped to the ITU-T V.24 [17] 
circuits (3G TS 27.001 [9]). 
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Table 2: Minimum set of V-series interchange circuits 



Circuit Number 


Circuit Name 


Ground 


Data 

to from 

TE2 TE2 


Control 

to from 

TE2 TE2 


CT102 


Common Return 


X 










CT103 


Transmitted 
data 






X 






CT104 


Received data 




X 








CT105 


Request to 
send 










X 


CT106 


Ready for 
sending 








X 




CT107 


Data set ready 








X 




CT108.2 


Data terminal 
ready 










X 


CT109 


Data channel 

received line 

signal detector 








X 




CT114 


Transmitter 

signal element 

timing 








X 




CT115 


Receiver 

signal element 

timing 








X 




CT125 


Calling in- 
dicator (note) 








X 





NOTE: CT125 is used with the AUTO ANSWER function of the TAP. 
Use of Networli Independent Clocldng: 

Network Independent Clocking is only applicable to calls using ITC value "3.1 kHz audio ex PLMN". 

Within the GSM network the coding of the values for bits associated with NIC is specified in GSM specifications 
GSM 04.21 [4] and GSM 08.20 [5]. In the forward (transmitting) direction the multiframes shall be coded in exact 
accordance with that specified in those specifications. Bit E6 is set to "1" in alternate modified ITU-T V.llO [22] 
frames at the transmitter. However, the use of this bit at the receiver for monitoring frame Synchronization, or any other 
purpose, is not specified and is left to the discretion of the implementor. 

A "perfect linear block Code" is used in C1-C5, whose error correction properties may be utilized in the receiver, in 
order to ensure reliable operation of NIC. 

The NIC sending function has to recognize when the difference between the applicable clock speed of the GSM 
network and the interface speed generates a positive or negative whole bit requirement. When this positive or negative 
condition occurs, the NIC codewords specified in specification GSM 04.21 [4] are used to transport this condition to the 
receiving NIC function. Transmission of the codeword shall clear the positive or negative condition related to that 
codeword at the sending function. The sending function shall not send more than one positive or negative 
compensations within a contiguous period of time corresponding to 10 000 user data bits minus the number of user data 
bits necessary to make up an even number of ITU-T V.l 10 [22] frames between compensations (NIC compensation is 
coded in two ITU-T V.l 10 [22] frames). This results from the requirements to compensate for maximum clock 
differences of + 100 parts per million. If the receiving function receives NIC compensations more often than a 
contiguous period of time corresponding to 10 000 user data bits, there is no guarantee that data will not be lost. 

The NIC receiving function has to provide the capability to support the compensation requirements of the sending 
function. This compensation is managed by manipulating the clock speed of the interface, within the standard 
constraints of that interface. 

Overall, the compensation functions have to be capable of managing clock tolerances of +100 parts per million. 

The NIC function has to recognize and manage the conversion of the NIC information received incoming from an ISDN 
terminal Interface. The conversion has to be made to the NIC format used within the GSM System as defined in 
specifications GSM 04.21 [4] and GSM 08.20 [5]). The NIC function has to manage the conversion of the GSM NIC 
format into that used within the ISDN in the traffic direction towards the ISDN terminal interface. 
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Due to the incompatibility between the ISDN and the GSM requirements NIC interworking is nor provided between 
these two formats, as such no NIC function is required in providing interworking to the ISDN for unrestricted digital. 

Action on loss of synchronization: 

If five consecutive NIC multiframes have incorrect framing bit values in E7, the receiver shall stop applying clocking 
compensation to the received data. Resynchronization shall be attempted and compensation shall resume when 
synchronization is achieved. 

Signal element timing: 

Receiver signal element timing (CTl 15) is generated by MT2. In the transparent case, this shall be synchronized to the 
output of RAT function. In the non transparent case it is output from the L2R on the basis of the current user data rate. 
A transition from ON to OFF condition shall nominally indicate the centre of each signal element on CTl 04. 

Transmitter signal element timing is generated by MT2 (CTl 14), this may be synchronized to CTl 15. 

In the case of alternate Speech/Group 3 Facsimile in GSM, there may be a Channel Mode Modify during the course of 
the facsimile portion of the call. If this occurs in GSM, the user data rate changes and this is reflected to the 
ITU-T V.24 [17] interface as a change in the clock speed on CT 1 14 and CT 1 15. 

4.2.1 .1 Multislot configurations (Channel coding TCH/F9.6 or TCH/F4.8 kbit/s) 

In transparent multislot configurations status bits SI, S3 and the X-bit between the D12 and D13 in the 

ITU-T V.l 10 [22] 80-bit intermediate rate frame - are used for transferring substream numbering information. The 

S4-bit is used for frame synchronization between the parallel substreams (ref GSM 04.21 [4]). 

4.2.1 .2 Channel coding TCH/F1 4.4 and TCH/F28.8 

For information on the mapping of the interchange circuit signalling bits in the 14,5 multiframe structure, refer to 
GSM 04.21 [4]. 

4.2.2 ITU-T X.21 [23] Interchange circuit mapping 

The interchange circuit signalling mapping at the interface between the TE2 and the MT shall conform to ITU-T 
recommendations ITU-T X.21 [23] and ITU-T X.24 [25]; while the signal levels at the interface shall conform either to 
ITU-T recommendation ITU-T X.26 [26]/(ITU-T V.IO [13]), or to ITU-T X.27 [27] /(ITU-T V.l 1 [14]) - see also 
paragraph 2.1 of ITU-T recommendation X.21 [23], or to IrDA IrPHY Physical signalling standard specification [34], 
or to PCMCIA 2.1 [33], or to PC-Card 3.0 [33] electrical specifications or to later revisions. 

The signals required at this interface are shown in table 3. 

Specification GSM 04.21 [4] refers to the frame structure and identifies the use of status bits for the carriage of 
signalling information. 

Status bits (SI, S3, S4, S6, S8, S9): 

For the purpose of alignment with the case where the ITU-T X.21 [23] TE2 is connected to the MT via a TA 
conforming to ITU-T recommendation X.30 [28], the notation for the S-bits shall be SP, SQ and SR as in figure 5 in. 
For the bits SP, SQ and SR, a ZERO corresponds to the ON condition, a ONE to the OFF condition. 

The bits SP, SQ and SR are used to convey channel associated status information. The mapping of the information on 
circuit C of the ITU-T X.21 [23] interface to the S bits and from the S bits to the circuit I in the distant interface should 
be done in such a way that the SP, SQ and SR bits are associated with the bit-groups P, Q and R. To assure proper and 
secure operation the mapping scheme has to be consistent with ITU-T recommendations X.21 [23]and X.24 [25]. 
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The mechanism for mapping is as follows: 

in all cases where ITU-T X.21 [23] - byte timing interchange circuit B is not provided, the status bits SP, SQ and 
SR of the bit groups P, Q and R are evaluated by sampling the circuit C in the middle of the 8th bit of the 
respective preceding bit group. On the other hand, the conditions of the status bits SP, SQ and SR are adopted by 
the circuit I beginning with transition of the respective 8th bit of a bit-group P, Q and R to the first bit of the 
consecutive bit group on the circuit R; 

in the case where ITU-T X.21 [23]-byte timing interchange circuit B is provided for character alignment, the 
circuit C is sampled together with the bit 8 of the preceding octet and the circuit I is changing its state at the 
boundaries between the old and new octets at the circuit R. This operation is defined in ITU-T recommendation 

X.24 [25]. 

Table 3: ITU-T X.21 [23] interchange circuits 



Interchange 
circuit 


Interchange circuit 
name 


to 
TE2 


ita 

from 
TE2 


Control 

to from 
TE2 TE2 


Timing toTE2 


G 


Common return 












Ga 


TE2 common return 












T 


Transmit 




X 




X 




R 


Receive 


X 










C 


Control 








X 




1 


Indication 






X 






S 


Signal element timing 










X 


B 


Byte timing (note) 










X 



NOTE: According to ITU-T recommendation X.21 [23] the provision of the 8 bit timing interchange circuit B is 
not mandatory. 

4.2.3 Case of ITU-T S-interface 

At the S-interface an ITU-T X.30 [28] rate adapted bit stream is provided by the TEl or TE2-TA combination (see 
figure 4). The terminal adaptation function within the MT does not have any interchange circuit signalling mapping 
function to perform. 

4.3 Call establishment signalling mapping at TE/MT interface 
4.3.1 ITU-T V-series interfaces 



4.3.1.1 



VOID 



4.3.1 .2 Call establishment manual operation - utilizing the Unrestricted Digital 

Capability 

In this case the user shall not hear network supervisory tones or answer tone. The data transfer phase shall be entered 
automatically. 



4.3.1.3 



ITU-T V.25 bis [1 8]auto call/auto answer 



The mapping of the ITU-T V.25 bis [18] procedures to the messages of the PLMN Dm-channel signalling 
(3G TS 24.008 [7]) is defined in clause 4. 

Auto Call: 

This procedure is provided according to ITU-T V.25 bis [18] using only circuit 108/2. A subset of ITU-T V.25 bis [18] 
is shown in table 4. This subset gives minimum level of control and indication. 
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During the call establishment phase, i.e. after signalling, call tone according to ITU-T V.25 bis [18] shall be generated 
in the IWF, where appropriate. 

Auto Answer: 

This procedure is provided according to ITU-T V.25 bis [18]. 

Table 4: Minimum set of ITU-T V.25 bis [18] Call Set-up Commands and Indications 





Description 


lASCharacters 


Commands 
from TE2 


Call Request with Number 
provided 0,1. .9,*,#,A,B,C,D 
Disregard Incoming Call 
Connect Incoming Call 


CRN 

DIG 
CIC 


Indications 
toTE2 


Call Failure Indication 

XX = CB,AB,NT,FC(Note) 

INcoming Call 

VALid 

INValid 


CFIXX 

INC 
VAL 

INV 



NOTE to table 4: CB = Local MT busy 
AB = Abort call 
NT = No answer 
FC = Forbidden call (*) 

(*) Forbidden call indication results from contravention of rules for repeat call attempts as defined by the 

appropriate national approvals administration. It is recommended that this is the responsibility of the MT, 
not the TE2. 

4.3.2 ITU-T X-series interfaces 

4.3.2.1 ITU-T X.21 bis [24] call establishment manual operation - utilizing the 

Unrestricted Digital Capability 

In this case the user shall not hear network supervisory tones or answer tone. The data transfer phase shall be entered 
automatically. 



4.3.2.2 



ITU-T X.21 bis [24] /ITU-T V.25 bis [18] call establishment signalling mapping 



The mapping of the ITU-T V.25 bis [18] procedures to the messages of the PLMN Dm-channel signalling 
(3G TS 24.008 [7]) is defined in clause 6. 

Auto Call: 

This procedure is provided according to ITU-T V.25 bis [18] using only circuit 108/2. A subset of ITU-T V.25 bis [18] 
is shown in table 4. This subset gives minimum level of control and indication. 

Auto Answer: 

This procedure is provided according to ITU-T V.25 bis [18]. 



4.3.2.3 



ITU-T X.21 [24] call establishment signalling mapping 



The mapping of the ITU-T X.21 [24] procedures to the messages of the PLMN Dm-channel signalling 
(3G TS 24.008 [7]) is defined in clause 7. 
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4.3.3 ITU-T S-interface (ITU-T 1.420 [11]) signalling mapping 

The mapping of ITU-T Q.931 [12] signalling to 3G TS 24.008 [7] signalling requires the inclusion, by the MT, of 
PLMN specific elements (eg. transparent or not, half or full rate channel). The required Bearer Capability Elements are 
shown in 3G TS 27.001 [9] annex 2. 

4.3.4 Void 



5 Terminal Adaptation Functions for synchronous 

non-transparent services in GSIVI 

5.1 Rate Adaptation and protocol model 

5.1.1 ITU-T R-interface 

For the protocol model and rate adaptation function applied in this case see Models 4b and 4e of figures 6, 7 and 8 in 
GSM 03. 10 [2]). 

5.1.2 ITU-T S-interface 

For the cases where the method indicated in ITU-T X.30 [28] is used see Models 4a and 4d of figures 6, 7 and 8 in 
GSM 03.10 [2]). 

For the cases where the HDLC interframe flag stuffing shown in the recommendation ITU-T X.31 [29] is used see 
Models 4c and 4f of figures 6, 7 and 8 in GSM 03.10 [2]). 

5.2 Signalling Mapping (GSM only) 
5.2.1 Interchange circuit signalling mapping 

Status bits SA, SB and X are used to convey channel control information associated with the data bits in the data 
transfer state. Table 5 shows the mapping scheme between the ITU-T V.24 [17] circuit numbers and the status bits for 
the non-transparent mode. It also shows how the unused status bits should be handled. It is derived from the general 
mapping scheme described in annex C. A binary corresponds to the ON condition, a binary 1 to the OFF condition. 

The transport of the status bits by the L2RCOP is described in annex A. 
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Table 5: Mapping scheme at the lUIT for the non-transparent mode 



Signal at TE2/MT 

interface or condition 

within the MT 


lUlapping 
direction: lUIT to IWF 


Mapping 
direction: IWF to MT 


CT105 


not mapped (note 1) 




CT 106 (note 4) 




from status bit X (note 7) 


CT107 




not mapped (note 5) 


CT 1 08/2 


not mapped (note 6) 




CT109 




from status bit SB 


CT 133 (note 8) 


To status bit X (notes 3,8) 




always ON 


to status bit SA (note 2) 




always ON 


to status bit SB (note 1) 




ignored by MT 




from status bit SA (note 2) 


NOTE 1 : The SB bit towards the IWF, according to the General Mapping (27.002, 

annex C), could be used to carry CT 105. However, CT 105 should 

always be ON in the data transfer state since only duplex operation is 

supported. Also, many DTEs use the connector pin assigned to CT 105 

for CT 133. No interchange circuit shall be mapped to the SB bit, which 

shall always be set to ON in the data transfer state. 
NOTE 2: The SA bits (both directions) are not mapped since CTs 1 07 and 1 08/2 

are handled locally (notes 5, 6). 
NOTE 3: The condition of status bit X towards the IWF may also be affected by the 

state of the receive buffer in the MT. 
NOTE 4: The state of CT 1 06 (or other local flow control mechanism) may also be 

affected by the state of the transmit buffer in the MT and the state of the 

RLP (RR/RNR). 
NOTE 5: CT 1 07 is controlled by the channel synchronisation process 

(3G TS 27.001 [9]). 
NOTE 6: CT 108/2 may be used in the call setup and answering processes. 
NOTE 7: For inband local flow control, changes in the condition of the status bit X 

from the IWF also result in the sending of XON or XOFF to the DTE. 
NOTE 8: For inband local flow control, CT 1 33 is not mapped and the status bit X 

towards the IWF is controlled by the reception of XON and XOFF 

characters from the DTE. 



5.2.2 Call establishment signalling mapping 

FFS 



5.3 



Flow Control 



The passage of flow control information between L2Rs is described in annex 1 . 

5.3.1 Conditions requiring flow control towards the network 

The L2R function shall send immediately a "flow control active" indication in the following circumstances: 

(i) if the receive buffer from the radio side reaches a preset threshold; 

(ii) if local flow control is initiated by the TE2 (see subclause 5.3.3 a)). On receipt of this flow control indication 
transmission of data from the receive buffer towards the TE2 is halted. 

On removal of the buffer congestion or local flow control the L2R shall send a "flow control inactive" indication. 

In addition, for the local flow control condition, transmission of data from the receive buffers shall be restarted. 
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5.3.2 Conditional requiring flow control towards TE2 

The L2R function shall immediately activate local flow control (see subclause 5.3.3 b)) under the following 
circumstances: 

(i) the transmit buffer reaches a pre-set threshold; 

(ii) the L2R receives a "flow control active" indication. 

On removal of the buffer congestion or receipt of L2R/RLP "flow control inactive" the local flow control shall be 
removed. 

5.3.3 Local flow control 

Only inband flow control is allowed: 

a) from TE2: 

RNR is sent to indicate flow control active. RR is sent to indicate flow control inactive. Where RR/RNR is 
utilized then the TAF shall generate flow control active/inactive immediately. 

b) from TAF: As from TE2. 

where this method is used, the L2R shall pass the RNR/RR frames to the TE2. 

5.4 Buffers 

5.4.1 TX buffers 

Data received from the TE2 shall be buffered such that if the MT is unable to transfer the data over the radio path then 
data is not lost. 

The buffer shall be capable of holding nl bytes. When the buffer is half full, TE2 shall be flow controlled as per 
subclause 5.3.2. The value for nl is up to the implementors. 

5.4.2 RX buffers 

Data for transfer to the TE2 shall be buffered such that if the TE2 is unable to accept data then data transferred from the 
MT is not lost. 

The buffer size should be n2 bytes. The value for n2 is up to the implementors. 

When the buffer becomes half full, the L2R shall send a "flow control active" indication. 
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6 V- and S-series interface procedures to 3G TS 

24.008 [7] mapping 

Interface procedures not directly mappable to 3G TS 24.008 [7] (ie. ITU-T V.25 bis [18] VAL/INV) are not considered. 
Mobile management procedures of 3G TS 24.008 [7] are not considered applicable. 

Mapping of other call establishment or clearing messages to the S interface e.g. "Call proceeding", etc. have not been 
included. It is assumed that these may be mapped directly and thus are of no relevance to the ITU-T V.25 bis [18] or 
manual interface. 



6.1 IVIobile Originated calls 



a) SET-UP. 



Element 


Derived from 


MIUII 


ITU-T V.25 bis [18] 


ITU-T S interface 






message 


message 


Called Address 


Keypad 


CRN/CRI/CRS 


Setup 


Called 


Keypad 


CRI 


Setup 


Sub Address 
HLC 






Setup 


Derived from internal settings or MM! information. 


LLC 


Same as HLC 


Setup 


BC 


Same as HSC 


Setup (with additional 




3G TS 27.001 [9] gives allowed values 


information from IVIMI 
oriented settings) 



b) RELEASE COMPLETE. 



Element 


Derived from 


lUIMI 


ITU-T V.25 bis [18] 
message 


ITU-T S interface 
message 


Cause 


Display (optional) 


CFI 


Release complete 



6.2 



Mobile Terminated calls 



Call establishment is initiated by receipt of Setup at the MS: 
a) SET-UP. 



Element 


lUlapped on to 


lUIMI 


ITU-T V.25 bis [18] 
message 


ITU-T S interface 
message 


Called Address 

Called 

Sub Address 

HLC 

LLC 

BC 


Display (optional) 
Display (optional) 

Display (optional) 
Display (optional) 
Display (optional) 


INC 

Not applicable 

Not applicable 
Not applicable 
Not applicable 


Set-up 
Set-up 

Set-up 

Set-up 

Set-up (with PLMN 

specific elements 

removed) 



b) CALL CONFIRM. 

Information for the BC element in the call confirm is derived from e.g. MMI or by internal settings. 

c) CONNECT. 

Connect is sent in response to connect from the S-interface, CIC from ITU-T V.25 bis [18] or from MMI. 
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7 ITU-T X.21 [23] interface procedures to 3G TS 

24.008 [7] mapping 

7.1 ITU-T X.21 [23] procedures mapping 

The ITU-T X.21 [23] procedures mapping is shown in figures 10 and 11. The Bearer Capability Elements required on 
Dm channel are shown in 3G TS 27.001 [9] annex 2. 

NOTE: DTE corresponds to TE2 and DCE corresponds to MT2 in the signal names of ITU-T X.21 [23] interface. 

7.1 .1 Mobile originated call (see figure 7) 

Call Request of TE2 to Dm channel SET-UP: 

At R interface: In Ready state both TE2 and MT transmit (l,OFF). When the calling TE2 indicates Call Request 
(0,ON), the MT transmits Proceed to Select (h-,OFF). Then the TE2 sends the Selection signals (lA5,ON) and End of 
Selection (h-,ON) and enters the state DTE Waiting (l,ON). The MT shall transmit DCE Waiting (SYN,OFF). 

At MS-MSC interface: By receiving Call Request at R-interface, the MT shall start mobile originated call establishment 
(CHANNEL REQUEST message etc.). When the MT has received Selection signals and End of Selection from TE2, it 
shall send SET-UP, when possible. 

CALL PROCEED: 

After the traffic channel assignment is complete, the MT shall start sending (1,0FF) within the 40 bit frames (see 
seubclauses 4.1.3 and 4.2.2) via the Bm (Lm) channel. 

Dm channel ALERT to Call Progress to TE2: 

This is applicable only to manually answered calls. 

When the MT receives ALERT from Dm channel, it shall transmit Call Progress signals (IA5,OFF) to TE2 and then 
enter the state DCE Waiting (SYN,OFF). 

Dm channel CONN to Ready For Data to TE2: 

When the MT receives CONN from Dm channel, it shall respond with CONN ACK message and it may send DCE 
Provided Information to the calling TE2. The MT transmits then Connection in Progress (l,OFF) to TE2. 

When the MT receives a frame with all data bits set to ONE, it performs the switch-through of data and control lines to 
TE2. 

7.1 .2 Mobile terminated call (see figure 7) 

Dm channel SET-UP to Incoming Call to TE2: 

When the TE2 is in Ready state and the MT receives SET-UP via Dm channel, the MT shall respond with ALERT in 
case of manual answering. Via R interface the MT transmits Incoming Call (Bell OFF) to TE2. 

Call Accepted of TE2 to Dm channel CONN: 

When the MT receives Call Accepted via R interface (l,ON), it shall send CONN message via Dm channel. 

Dm channel CONN ACK to Ready For Data to TE2: 

When the MT receives CONN ACK from Dm channel, it shall start sending (l,OFF) within the 40 bit frames via the 
Bm (Lm) channel. Via R interface the MT transmits Connection in Progress (1,0FF) to TE2 after delivering DCE 
Provided Information if any. 

When the MT receives a frame with all data bits set to ONE, it performs the switch-through of data and control lines to 
TE2. 
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7.1 .3 Mobile termination clearing (see figure 8) 

DTE Clear Request (0,OFF) is transmitted via Bm (Lm) channel to the cleared terminal. The MT at the clearing TE2 
recognizes the Clear Request, transmits DCE Clear Confirmation (0,OFF) to TE2 and sends DISCONNECT message 
via Dm channel. When the radio channel is released, the MT shall transmit DCE Ready (l,OFF) and TE2 shall then 
enter the state DTE Ready (l,OFF). 

7.1 .4 Distant end terminal clearing 

When the MT receives DCE Clear Request via Bm (Lm) channel, it shall transmit DCE Clear Indication (0,OFF) to its 
TE2 via R interface. After the MT has received DTE Clear Confirmation (0,OFF), it sends DISCONNECT message via 
Dm channel. When the radio channel is released, the MT shall transmit DCE Ready (l,OFF) and TE2 shall then enter 
the state DTE Ready (l,OFF). 

7.1 .5 Network generated clearing (see figure 8) 

When the MT has received DISCONNECT message via Dm channel, it shall transmit DCE Clear Indication (0,OFF) to 
its TE2 via R interface. After the MT has received DTE Clear Confirmation (0,OFF) and the radio channel is released, 
the MT shall transmit DCE Ready (l,OFF) and TE2 shall then enter the state DTE Ready (l,OFF). 
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Calling 
TE2 X.21 interface 



MT2 



MSC 



MT2 



Called 
X.21 interface TE2 





> Ready 


l.OFF . 


"": 


CHAN REQ . 




PAG REQ . 




. l.OFF 


Ready ^ 


■■: 


Call request 


l.OFF 
0.0N_^ 


l.OFF 
l.OFF 


r 
Incoming call^ 


, CHAN REQ 


l.OFF 
^ Proceed to select 0,ON 


. IMM ASS 


IMM ASS . 


SERV REQ . 


. PAG RES 


+.OFF 
Selection signals IA5.0N ^ 


w 

^ SERV REQ 


PAG RES. 


1 
. AUTH REQ 


AUTH REQ . 


DTE waiting 


r 
+.OFF 

l.ON . 


AUTH RES . 


. AUTH RES 


. CIPH CMD 


CIPH CMIL 


CIPH coiL 


, aPH COM 


r 
SETUP . 


SETUP . 


^ DCE waiting 


+.OFF 
l.ON 




>CALL PROG 


> CALLCONF 




BEL.OFF 

4 ^'^^ 


r 

Call accepted 


^ ASS CMD 


ASS CMD . 


J Call Progress 


SYN.OFF 
l.ON 


ASS COM . 


. ASS COM 







^ ALERT 


ALERT ^_ 


^ DCE waiting 


lAS.OFF 
l.ON 




1 
. CONN 


r 

. CONN 




CONN ACK . 






BEL.OFF 
l.ON 


DCE waiting ^ 


SYN.OFF 
J DCE information l.ON 


r 


A — ^- 

j Connection in 


lAS.OFF 

1,0N 






1 
CONN ACK . 






SYN.OFF 

l.ON DCE information ^ 


r 




1 

progress 

J Ready for data 


l.OFF 
l.ON 




/ 


("1") 


C'l") 


^ 




1A5.0FF 

l.ON 


r 
Connection in^ 




l.OFF 
l.ON 


r 

progress 
Ready for data^ 


> Data transfer 


l.ON 
FL.ON^ 


\ 


("I") 

(Flags) 


("i") 

(Flags) 


/ 


l.ON 
. FL.ON 


r 
Data transfer^ 


♦ 

J Data transfer 


FL.ON 
FR.ON. 




(Flags) 
(Frames) 


(Flags) 
(Frames) 




FL.ON 
. FR.ON 


r 
Data transfer^ 


t- - 


FR.ON 






(Frames) 


(Frames) 




FR.ON 


r 



NOTE: In the signal names of ITU-T X.21 [23] interface DTE corresponds with TE2 and DCE corresponds with 
MT2. 

Figure 7: Example of a calling and a called TE2 (ITU-T X.21 [23]) 
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DTE clear 



O.OFF 
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confirmation 
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NOTE: In the signal names of ITLi-T X.21 [23] interface DTE corresponds with TE2 and DCE corresponds with 
MT2. 

Figure 8: Example of a clearing and a cleared TE2 (ITU-T X.21 [23]) 

7.2 Dm Signalling causes mapping to ITU-T X.21 [23] call 
progress signals 

The mapping of PLMN Dm channel signalling to ITU-T X.21 [23] call progress signals and DCE Provided Information 
is shown in table 6. 
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7.3 ITU-T X.21 [23] FACILITIES MAPPING 

The ITU-T X.21 [23] facilities are shown in table 7. The mapping of these to PLMN supplementary services is for FFS. 
Table 6: Mapping of Dm cause fields to ITU-T X.21 [23] call progress signals 



Item 


Dm signalling cause 


Code 


ITU-T X.21 call progress signal sign. 


Code 


01 


Unassigned (unallocated) number 


01 


Not obtainable 


43 


02 


No route to destination 


03 


Not obtainable 


43 


03 


Channel unacceptable 


06 


Not obtainable 


43 


04 


Normal call clearing 


16 


— 




05 


User busy 


17 


Number busy 


21 


06 


No user responding 


18 


No connection 


20 


07 


User alerting, no answer 


19 


No connection 


20 


08 


Call rejected 


21 


Controlled not ready 


45 


09 


Number changed 


22 


Changed number 


42 


10 


Destination out of order 


27 


Uncontrolled not ready 


46 


11 


Invalid number format (incomplete) 


28 


Selection sign, procedure error 


22 


12 


Facility rejected 


29 


Invalid facility request 


48 


13 


Response to status enquiry 


30 


— - 




14 


Normal, unspecified 


31 


— - 




15 


No circuit/channel available 


34 


No connection 


20 


16 


Network out of order 


38 


Out of order 


44 


17 


Temporary failure 


41 


Out of order 


44 


18 


Switching equipment congestion 


42 


Network congestion 


61 


19 


Access information discarded 


43 


— 




20 


Requested circuit/channel not available 


44 


No connection 


20 


21 


Resources unavailable, unspecified 


47 


Network congestion 


61 


22 


Quahty of service unavailable 


49 


— 




23 


Requested facility not subscribed 


50 


Invalid facility request 


48 


24 


Bearer capability not authorized 


57 


Incompat. user class of service 


52 


25 


Bearer capability not presently available 


58 


Network congestion 


61 


26 


Service or option not available, unspecified 


63 


No connection 


20 


27 


Bearer service not implemented 


65 


Invalid facility request 


48 


28 


Only restricted digital information 
bearer capability is available 


70 


Invalid facility request 


48 


29 


Service or option not implemented, 
unspecified 


79 


Invalid facility request 


48 


30 


Invalid call reference value 


81 


Not obtainable 


43 


31 


Incompatible destination 


88 


Not obtainable 


43 


32 


Invalid transit network selection 


91 


Not obtainable 


43 


33 


Invalid message, unspecified 


95 


Selection signal transmis. error 


23 


34 


Mandatory info, element error 


96 


Selection signal procedure error 


22 


35 


Message type non-existent or 
not implemented 


97 


Selection signal procedure error 


22 


36 


Message not compatible with call state or 
message type non-existent or 
not implemented 


98 


Selection signal procedure error 


22 


37 


Information element non-existent 
or not implemented 


99 


Selection signal procedure error 


22 


38 


Invalid info, element contents 


100 


Selection signal transm. error 


23 


39 


Message not compatible with call state 


101 


Selection signal procedure error 


22 


40 


Recovery on timer expiry 


102 


Not obtainable 


43 


41 


Protocol error, unspecified 


111 


Selection signal procedure error 


22 


42 


Interworking, unspecified 


127 


RPOA out of order 


72 
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Table 7: ITU-T X.21 [23] facilities 



Facility 




request code 


Facility 


1 


Closed user group 


45 


DTE inactive registration 


45 


DTE inactive cancellation 


60 


Multiple address calling 


61 


Charging information 


62 


Called line identification 


63 


Redirection of callactivation 


63 


Redirection of callcancellation 


63 


Redirection of callstatus 


64 


Reverse status 


65 


Direct call registration 


65 


Direct call cancellation 


66 


Abbreviated address registration 


66 


Abbreviated address cancellation 



8 Void 
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Annex A (normative): 
L2R Functionality 



A.1 Introduction 



This annex describes the Layer 2 Relay (L2R) functionality required to support LAPB non-transparently. The general 
aspects of L2Rs are described in specification 3G TS 27.001 [9]. Figure 1 shows the three sub-functions of the L2R. 



LAPB 



BORE 



LAPB 
Entity 



L2RB0P 

Entity 



L2RB0P 



LAPB Link Access Protocol Balanced 
BORE Bit Oriented Relay Entity 
L2RB0P L2R Bot Oriented Protocol 

Figure 1 : Sub-functions of the L2R 

Clause 2 describes the L2R Bit Oriented Protocol (L2RBOP) and clause 3 describes the use of the L2RBOP to transport 
LAPB information fields. 



A.2 L2RB0P 



The LAPB user information fields and interface status changes are transferred between L2Rs using the services of the 
radio link. The L2RBOP entity segments and reassembles the LAPB user information fields to fit into the service data 
units (SDUs) handled by the radio link. I.e. segments of LAPB user information fields and interface status changes are 
transferred between L2Rs in n octet Protocol Data Units (PDUs). This corresponds to the fixed length of the RLP frame 
information field. The octets within the L2RBOP-PDU are numbered to n-1, octet is transmitted first. The value of n 
depends on the negotiated RLP version and frame type (3G TS 24.002 [8] ). The bits within the octets are numbered 1 
to 8, bit 1 is transmitted first. 

The RLP version value 2 indicates RLP multi-link operation. The RLP version value or 1 indicates RLP single-link 
operation. 

The L2RBOP also provides facilities for transferring LAPB connection control information between L2Rs. This LAPB 
connection control information allows concatenated LAPB connections to be established, reset and released. 

The L2RBOP PDUs are coded as follows: 

each octet contains a status octet, 1-8 bits of user information, control information or fill; 

octet shall always contain a status octet in case at least one status octet is transportet in the L2RBOP PDU. In 
RLP -versions and 1 a PDU always carries at least one status octet. In RLP version 2 a PDU carries status 
octet(s) only if actual status change(s) has taken place within the period represented by the PDU. Here the L2R 
status flag in the RLP version 2 header is set to 1 when status octet(s) is carried in the PDU; 
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status octets contain 3 status bits and 5 address bits. In cases where two status octets within the PDU are 
separated by more than 23 octets, the first status octet in octet m is followed by a pointer octet in octet m+1 
forming a two-octet status field. The pointer octet contains one reserved bit and seven address bits indicating the 
number of characters between the status field and the second status octet; 

the 3 status bits are used to convey the interface conditions that are conveyed by the S and X bits in ITU-T 
recommendations V.llO [22] and X.30 [28]. In the case of ITU-T V series interfaces the 3 status bits correspond 
to SA, SB and X bits specified in ITU-T V.l 10 [22]. In the case of ITU-T X series interfaces only 2 bits are used 
and these correspond to S and X bits specified in ITU-T X.30 [28]. The ITU-T V series SA, SB and X bits use 
bit positions 8, 7 and 6 respectively in the status octets. The ITU-T X series S and X bits use bit positions 7 and 6 
respectively, in this case bit position 8 is unused; 

LAPB user information is carried in L2RBOP-PDU information octets such that the first LAPB user information 
bit, in any consecutive group of 8, received or transmitted corresponds to bit position 1 in the octet. The second 
to bit position 2, etc.; 

information octets are inserted into the L2RBOP-PDU in order of arrival in octets 1 to n-1 for RLP single-link 
operation, in octets 1 to n-1 for RLP multi-link operation with status octet transportation and in octets to n-1 
for multi-link operation with no status octet transportation; 

the address field in the status octets indicates the position of the next status octet within the L2RBOP-PDU. This 
indicates the number of information octets between status octets. Thus if two status octets are inserted into an 
L2RB0P-PDU at offsets 1 and m the address field value for the status octet at offset 1 shall be defined by m-1-1 
(m>lH-l). The low order bit of the address corresponds to bit 1 of the octet and the high order bit to bit 5; 

status octets are inserted in the information stream whenever a status change needs to be transmitted; 

only address values 1 to n-2 (n-2 < 23) in the address field of status octets are used for addressing purposes. The 
implication of not allowing address value to be used for addressing is that two status octets can not be sent 
after each other. The remaining codes are used to indicate: 

last status change, remainder of L2RBOP-PDU is empty. Address field value is 3 1 ; 

last status change, remainder of L2RBOP-PDU full of information octets. Address field value is 30; 

end of a LAPB user information field. Address field value is 29. This is used to delimit LAPB user 
information fields. In this case the 3 status bits do not have their usual meaning. They are used to indicate the 
number of information bits in the previous information octet. A binary number in the range to 7 is 
contained in bit positions 8, 7 and 6, bit 6 is the low order bit. The values 1-7 indicates the number of 
information bits used, value indicates all bits used. If this octet is not on the last position in a 
L2RB0P-PDU another status octet follows (e.g. an End of LAPB user information field in octet is followed 
by a status octet in octet 1); 

abort a LAPB user information field transfer. The address field value is 28. This is used to abort the 
transmission of a LAPB user information field after sending one or more segments in L2RBOP-PDUs. If this 
octet is not on the last position in a L2RBOP-PDU another status octet is following (e.g. an Abort a LAPB 
user information field transfer in octet is followed by a status octet in octet 1); 

- L2RBOP-PDU contains at least two status octets which are separated by more than 23 characters; the 

address-field value in the first octet of the two-octet status field is 27 and the address bits in the pointer octet 
of the status field indicate the number of characters between the two-octet status field and the next status 
octet. 

address field values from n-1 to 26 are reserved. In case of a PDU more than 25 octets in length, address field 
values from 24 to 26 are reserved.- When it is necessary to insert a status octet into the information stream when 
no status change has occurred, e.g. to indicate that the remainder of an L2RBOP-PDU is empty or to indicate end 
of a LAPB user information field, the current status shall be repeated; 

in case when 64 data octets are carried by a 66-octet PDU, a status octet is carried in octet and another status 
octet within the first 24 data octets. (The first status octet gives the address of the second status octet, which 
carries value 30 in its address field); 

LAPB connection control information is transferred between L2Rs by use of a connection control PDU. 
Connection control PDUs consists of an L2RB0P PDU with the status octet in octet containing address field 
value 0. The coding of the remainder of the L2RB0P connection control PDU is as follows: 
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octet 1 contains the connection number, always for LAPB. Other values are reserved for future use; 

octet 2 contains the connection control information. The connection control information values are 1 for 
Connect, 2 for Reset, 3 for Disconnect and 4 for loss of LAPB interframe fill. This octet is coded as a binary 
number with the low order bit corresponding to bit 1 ; 

the use of octets 3 to n-1 is reserved. 

LAPB exchange identification frames (XID) are transferred between L2Rs by use of exchange identification 
PDUs. These PDUs consist of L2RB0P PDUs with the status octet in octet containing address field values 0. 
The coding of the remainder of the PDU is as follows: 

octet 1 contains the connection number, always for LAPB. Other values are reserved for future use; 

octet 2 contains the exchange identification indication. The values are 5 for an Exchange Identification 
Request and 6 for an Exchange Identification Acknowledge. The values 7 to 255 are reserved. This octet is 
coded as a binary number with the low order bit corresponding to bit 1 ; 

the octet 3 contains a normal status octet. The rest of the PDU and of the following PDUs, if any, is used to 
transfer the XID information and it is treated like normal user data information PDUs as far as the coding is 
concerned. 



A.3 Use of the L2RB0P 



The L2R function required to support LAPB non-transparently consists conceptually of the three sub-functions shown 
in figure 1, i.e. the LAPB entity, the BORE and the L2RBOP entity. These perform the following functions: 

- LAPB entity - This terminates the LAPB protocol from the terminal or the network. The service provided by the 
LAPB entity to the BORE is described in ISO DIS 8886.2 [32] - OSI Data link service definition; 

L2RBOP entity - This uses the services provided by the radio link, see specification 3G TS 24.022 [8]. The 
service provided by the LAPB entity to the BORE; 

BORE - This concatenates the data link services provided by the use of the L2RBOP and LAPB. 

The functions are described in more detail in the following subclauses. 

A.3.1 Radio Link Connection Control 

The L2RBOP entity uses the services of the radio link to establish, reset and release the connection to its peer L2RBOP 
entity. The radio link connection shall be established and released as a result of indications from the signalling 
mechanisms when the supporting circuit switched connection is established. 

After an RLP reset or RLP disconnect the L2RBOP entities shall assume that the remote LAPB connection is in 
disconnected state. No data can therefore be transported between the L2RBOP entities before an exchange of the 
connection control PDU "Connect" has taken place. All connection control PDUs transferred before the RLP reset are 
no longer valid and must not be acknowledged. All PDUs (except XID) received by the L2RBOP entities after an RLP 
reset or disconnect and before a new connection control PDU "Connect" has been received shall be discarded by the 
L2RBOP entity. 
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A.3.2 Status transfer 

The L2RBOP entity transfers interface status information between L2Rs via the status octets in the L2RBOP-PDUs. 
The meaning of the bits is exactly the same as that defined in ITU-T recommendation V. 1 10 [22]and X.30 [28]. Status 
changes are inserted in the L2RBOP-PDU in the position corresponding to the position in the information stream at the 
DTE/DCE interface that the interface status change occurred. When the RLP is established or reset a L2RBOP-PDU 
with the current status octet shall be sent. 

A.3.3 LAPB connection control 

The L2RBOP entity transfers LAPB connection control information between L2Rs via the L2RBOP connection control 
PDUs. This allows a LAPB connection to be established, reset and released when the remote LAPB connection is 
established, reset and released or vice versa. L2RBOP connection control PDUs containing connect or reset requests 
shall be acknowledged by a similarly coded L2RBOP connection control PDU in the reverse direction. Data transfer 
between L2Rs is not allowed until the connection control acknowledge PDU is received. 

In the case of requests crossing they shall each be treated as acknowledgements of the other. 



A.3.4 LAPB exchange identification 



The L2RB0P entity transfers a LAPB exchange identification request/acknowledge between L2Rs via the L2RBOP 
exchange identification PDUs. This allows transfer of identification information prior to link establishment and/or 
during the link (especially with respect to ISO 8885 [31]/DADI). A L2RB0P exchange identification request PDU shall 
be answered by an associated exchange identification acknowledge PDU. In case of crossing of two requests each 
request shall be answered individually. A LAPB exchange identification request with identification information shall be 
acknowledged by the LAPB entity from L2R only when the acknowledge from the remote LAPB connection is 
indicated by an exchange identification acknowledge PDU sent by the remote L2RBOP entity. 

A.3.5 Data Transfer 

The L2RB0P entity assembles and disassembles L2RBOP-PDUs by segmenting and reassembling the LAPB user 
information fields. 

A.3.6 Flow control 

Flow control information is transferred between L2Rs in two ways, these are: 
- back pressure caused by L2R buffer conditions; 
use of the X-bit in the status octet; 
X = 1 flow control active; 
X = flow control inactive. 
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